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[57] ABSTRACT 

A database synchronizer facilitates computing systems 
which have client-side and server-side applications that 
share data in similar database structures, but which do not 
maintain a continuous connection to a single shared data 
source. In general, a database synchronizer is used to share 
data among many nodes on the computing system. The 
database synchronizer is used to synchronize the data in a 
central database for a particular client with the data on that 
client's intermittently-connected computer. Updates per- 
formed by either client or server are propagated to the other 
side when a connection is established and eventually from 
the server to other clients in the system, 
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DATABASE SYNCHRONIZER remote (client) database is generally limited to data related 

to the respective client. The database synchronizer is used to 

BACKGROUND OF THE INVENTION synchronize the data in the central database with the data on 

„ , ■ . each client's computer. 

Portable computers are becoming more and more popular r ..it. 

in the business world. In addition to being convenient, 5 , BrieB y> me database synchronizer described herein per- 

portable computing allows an organization to extend its forms database synchronization between a client database 

production system further into the field. Whether a user is and a database ■ three-step process. First the 

taking orders, doing field service, or delivering packages, chenl determines what modifications to the client data have 

the user is executing transactions against an organization's ,„ taken place since the last time of synchronization. The 

production system. Portable computers enable a user to 10 modifications detected are the creation of a new data item, 

perform these transactions on the spot and in a timely an update to the value of an existing data item and the 

manner deletion of a data item. Under one approach, the client 

, , , . . _ . detects modifications by comparing the client data with a 

A user of a portable computer is in effect, operating as a of me client data< ^ be f 0 re-image is effec- 

chent to the organization s production system server. The 15 a rf ^ ^ ^ ag of me ^ ^ {t wag 

chent is, however, not usually connected to the server and chrooi ^ Second> the modifications m prop ag a ted to 

must operate autonomously, such as by taking orders or ^ M ^ determined what cn hav * taken 

querying the status of orders. To successfully perform these _ Antn ■ ^ tUn w ~c 

, , . . , . e : * i place to the server data since the last tune or synchroniza- 

tasks, the chent maintains a local replica of the server s data. f. r - „ tU , „ 4 , . # , 

' * tion. Finally, the server detects data conflicts, resolves them, 

While multiple copies of data exist, these copies need to 20 a nd propagates modifications back to the client as refresh 

be kept consistent. While disconnected, applications at each data 

client and at the server may modify their data. To achieve A c , 4 . . , , . 4 . 

J A , J . j-j. j,,. A preferred computing system embodying the invention 

consistency, connections must be made and individual ch- • 1 j « i_ ■ * 1 j * L r 

t 1 ■ • includes a server computer having a central database for 

ents synchronized with the server. In this way, modifications * ■ j * *u • j u * r * 

, ' ^ , . J , storing data therem and any number of chent computers 

made at one client are propagated to the server and even- 25 u • uu-ij j * 1 ■ * j 

. f * b havmg a remote database which includes data replicated 

tually to each client as it connects. c . 1 j . u „ . _i « »_ j.l 

J trom the central database. Both the remote database and the 

The synchronization is difficult to achieve, even in situ- centra ] database organize the data as any number of collec- 

ations where the server and all clients are running the same t j ons 0 f dala w i th the data representable as row and 

database management system software. Unfortunately, this columns. In a preferred embodiment of the invention, the 

is not generally the case. Clients are often personal com- 30 databases are relational databases which organize data in 

puters running single-user database software whereas the labies of rows and vfvxxsm of data fields. A common 

server is usually a higher-powered multi-user system run- structure of shared columns between the server and the 

ning very different database software designed to hold much client ^ defined by an aspect of the invention called a table 

more data and service many users. correspondence. A table correspondence is defined as an 

One prior art approach to synchronization has been to 35 ordered fist of the shared columns. One or more table 

transmit a copy of the replica from the server to each client. correspondences are stored in a catalog, another aspect of 

This approach is possible when all modifications are done at the invention. Copies of the catalog are stored at the server 

the server and propagated to the client for read-only use. and client. 

When updates can also occur at the client, separate table A database synchronizer divided between at least one 
pairs can be used to propagate changes in each direction. c ij ent and a server is used to synchronize the central data- 
Many organizations have, in the absence of any specific base and the remote database at an arbitrary time selected by 
tools, developed adhoc solutions. These are time consuming each client. The database synchronizer uses the table corre- 
to develop, difficult to maintain, non -general, and less reli- spondence as a common reference between the client and 
able in that they generally do not properly recover from 45 server to identify the tables and columns of the databases 
errors such as power failures, line failures, and system which it is to synchronize. 

crashes. Th e database synchronizer preferably synchronizes tabu- 

SUMMARY OF THE INVENTION la J b h e,weei \ a ° f com P ) uters - For "X ?™ 

of tables to be synchronized, the database synchronizer 

As used herein, the term synchronize is defined to be the 50 determines which modification occurred at the client. In one 
act whereby data in two databases are restored to coasis- approach, the modification is determined by comparing the 
tency. That is, updates performed by either client or server table with a before-image of the table, taken at the time of 
are propagated to the other side when a connection is last synchronization. There is a row modification if any 
established and eventually to other clients in the system. A column of a row in the table differs from that found in the 
goal of the database synchronizer is to minimize the cost of 55 before-image table, or if a row is present in one but not the 
synchronization by reducing communication costs and other. Corresponding modification messages are then trans- 
delays in synchronizing the database data. mitted from the client to the server. 

A database synchronizer in accordance with the invention The server receives the modification messages and pro- 
facilitates computing systems which have client-side and cesses them to determine if the client's operation is in 
server-side applications that share data in similar organiza- 60 conflict with operations that have taken place at the server, 
tional structures, but which do not maintain a continuous If there is no conflict, or if the conflict is resolved in favor 
connection to a single shared data source. The database of the client, the server modifies the corresponding row in 
synchronizer is a general purpose system which accommo- the tabular database at the server. Once the tabular database 
dates heterogeneous computers and databases. In general, a at the server is updated with the values from the client, the 
database synchronizer is used to share data among many 65 server determines refresh data to transmit to the client. The 
nodes on the computing system. While a central (server) client modifies its tabular database with the refresh data to 
database includes information from all the clients, each bring the two databases into synchronization. 



07/25/2003, EAST Version: 1.03.0002 



5,926,816 



In accordance with one aspect of the invention, synchro- 
nization costs are reduced by a message structure which 
minimizes the length of data messages transmitted between 
the client and server. In particular, modification messages 
are built specifying a minimal amount of information nec- 
essary to modify a row of the database on either the client 
or the server. Although each message includes information 
identifying a particular row, the message can include modi- 
fication information for a plurality of columns represented in 
the row. The plurality of columns are preferably encoded in 
a single field of the message. 

In accordance with another aspect of the invention, the 
clients and server cooperatively maintain a catalog structure 
on each computer. Catalogs on the client and server manifest 
table correspondences that list in a common, indexed order 
all the columns of the replicated tables on that computer. 
That is, a replicated column on the server and the replica 
column on the client have the same index value into the 
respective table correspondences. That index into the table 
correspondences is used to identify the column in messages, 
thereby eliminating the need to explicitly pass the column 
numbers between computers. The indices are passed in the 
modification message to identify columns having modified 
data. 

The indices are preferably encoded into a bitmapped field 
in the message. Alternatively, the index values can be 
directly passed in the message. In a particular preferred 
embodiment of the invention, the decision whether to bit- 
map or to directly pass the indices is made dynamically on 
a row-by-row basis. 

In accordance with yet another aspect of the invention, the 
client maintains two versions of a table to be synchronized. 
Both versions are created as identical copies at the time of 
synchronization. One version is actively modified by the 
client and contains the current values of the data fields. The 
other version is a bef ore-image of the replica database 
created at refresh. The modifications to the database are 
determined by a difference comparison between the current 
values in the active table and the before values in the 
befo re-image table. Although the use of a befo re -image table 
increases the overhead at the client by as much as doubling 
the storage requirements, the use of two table versions 
enables the database synchronizer to be used with any set of 
tables (or other collections of data) regardless of whether the 
database management software, if any, provides any mecha- 
nism for automatically logging changes. Thus the database 
synchronizer can work with tabular data even if not main- 
tained using database management software, e.g., spread- 
sheet data or columnar data stored in a text file. 

In accordance with yet another aspect of the invention, the 
database synchronizer uses a "smart differencing" technique 
to minimize storage requirements of the before-image table 
(s). The developer specifies in the catalog which fields are 
not modifiable at the client. This enables the database 
synchronizer to omit such fields in the before-image table as 
long as the fields are also not used to uniquely identify a 
given row. 

In accordance with yet another aspect of the invention, the 
server detects data conflicts and resolves those conflicts. The 
server maintains an update log of all operations on the 
server's replicated data since the time of last refresh for each 
client. For each row, and with respect to a particular client, 
the server iterative ly processes the logged entries in the 
order the updates were applied to determine a server effec- 
tive operation and a before value for the row. The server 
effective operation is a single operation which yields the 
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same result to a client row as would the logged server 
entries. The before value is the value of a row at a particular 
client before the last propagation of a modification to that 
row from the client. The server effective operation and the 
before value are calculated from logged column values 
based on the logged operations and the client instigating 
each operation. By comparing the server effective operation 
and current row values with the operation propagated from 
the client and the calculated before-values, the server detects 
conflicts. The conflict is then resolved in favor of either the 
server or the client so proper values are stored in the server's 
database. 

In accordance with yet another aspect of the invention, the 
server propagates refresh data to the client in response to a 
request from the client. Because columns on the server can 
be updated by another node without a propagation of the 
current value from the client, the server must calculate the 
current values on the client to determine the data to include 
in a refresh message. The server uses the server effective 
operation for each row to deduce the current values in the 
client's active database by comparing the server effective 
operation with the row as stored in the server database and 
with timestamps stored in the update log. Those deduced 
current values are then compared with the values in the 
server database. The server propagates differences to the 
client as refresh data. 

The server thus uses the update log for two purposes. The 
server uses the update log to create a view of the client's old 
values for conflict detection and then a view of the client's 
current values for refreshing the client. Both views are 
deduced from the update log without the client providing 
explicit information to the server. The process is based on 
knowing what a client's values are at the last refresh time 
and recreating client update activity from update operations 
performed by that client since that time. Consequently, the 
server can perform conflict detection and can formulate the 
effective database operations needed to bring the client into 
synchronization with the server while minimizing the 
amount of information communicated to the server by the 
client. 

Communication errors or errors at either client or server 
can result in tables that are not properly synchronized. For 
the greatest, reliability, proper synchronization should be 
frequently verified. The verification must perform well even 
on clients with slow disks and CPUs. To facilitate this 
verification, the server calculates a checksum value for the 
client from the server's view of the client table. The server 
then sends that calculated server checksum to the client. For 
the data to be valid, a checksum performed on the refreshed 
client table by the client must match the calculated server 
checksum. Preferably, the client calculates the client check- 
sum from a before-image of the client table. That before- 
image is stored immediately after the refresh and the cal- 
culation of the client checksum is performed during the 
client propagation processing, instead of immediately after 
the refresh. Thus the client risks the use of invalid data. That 
risk, however, is exchanged for more efficient processing. 

A preferred database synchronizer in accordance with the 
invention also facilitates two-way filtering between the 
client and server. That is, both the client and the server can 
apply filters to the data in the respective database tables. 
Preferably, both row (horizontal) and column (vertical) 
filters can be used in the database synchronizer. This allows 
users to maintain private data, including rows or columns on 
either the client or server, which is not shared between 
databases. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The above and other features of the invention, including 
various novel details of construction and combination of 
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parts, will now be more particularly described with reference 
to the accompanying drawings and pointed out in the claims. 
It will be understood that the particular database synchro- 
nizer embodying the invention is shown by way of illustra- 
tion only and not as a limitation of the invention. The 
principles and features of this invention may be employed in 
varied and numerous embodiments without departing from 
the scope of the invention. 

FIG. 1 is a schematic block diagram of a client-server 
database system in accordance with the invention. 

FIG. 2 is a schematic block diagram of a client node 
having a client-side database synchronizer embodying the 
invention. 

FIG. 3 is a schematic block diagram of a server having a 
server-side database synchronizer embodying the invention. 

FIG. 4 is a schematic diagram of database table schemas 
implemented on the server node and a particular client node 
of FIG. 1 

FIGS. 5 A and 5B are flowcharts illustrating the major 
steps for performing a server database synchronization in 
accordance with the invention. 

FIGS. 6 A and 6B are flowcharts illustrating the major 
steps for performing a client database synchronization in 
accordance with the invention. 

FIG. 7 is a schematic diagram of a table row message. 

FIGS. 8A and 8B are schematic diagrams illustrating an 
exemplary client database and central database, respectively. 

FIGS. 9Aand 9B are schematic diagrams of a table view 
of a replicated server-side and client-side database table, 
respectively. 

FIGS. 10A and 10B are schematic diagrams of the client- 
side catalog and before -image log table, respectively, for the 
server table of FIG. 9A. 

FIGS. 11 A, 11B and 11C are schematic diagrams of the 
server-side catalog, server update log table, and refresh table 
for the server table of FIG. 9B. 

FIGS. 12A and 12B are schematic diagrams of a modified 
server table and a corresponding server update log table. 

FIG. 13 is a schematic diagram of a modified client table. 

FIGS. 14A and 14B are schematic diagrams of table row 
messages from the client node to the server node for the 
modifications to the client table illustrated in FIG. 13. 

FIGS. 15A and 15B are schematic diagrams of an updated 
server table and an updated server update log table, respec- 
tively, 

FIGS. 16 A and 16B are schematic diagrams of refresh 
messages from the server node to the client node for the 
updated server table of FIG. 15 A. 

FIGS. 17A and 17 B are schematic diagrams of a refreshed 
client table and the corresponding before-image log table, 
respectively, after applying the refresh data of FIGS. 16 A 
and 16B. 

FIG. 18 is a schematic diagram of an updated refresh table 
after the refresh of FIG. 17A. 

FIG. 19A-19B are logic tables illustrating the use of a 
server effective operation during the database synchroniza- 
tion of FIGS. 8A-18. 

DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENTS OF THE INVENTION 

A database is, in general, a collection of data and software 
programs to manipulate the data. The database maintains 
data through arbitrary modification operations, such as 
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insert, update and delete operations. Two types of databases 
in common use are object-oriented and relational databases. 
A preferred embodiment of the invention is described herein 
as a synchronizer for a relational database. 

FIG. 1 is a schematic block diagram of a client-server 
database system in accordance with the invention. As 
illustrated, there is a server node 10 and a plurality of client 
nodes 20a, . . . ,20*, . . . ,20z, each of which having a unique 
node identifier a, . . . ,x, , . . ,z. The server node 10 includes 
at least one processing core 11 comprising a processor and 
memory for accessing and maintaining a central database 12. 
Preferably, the central database 12 is a relational database 
such as, for example, Oracle 7 available from Oracle Cor- 
poration. 

Each client node 20a, . . . ,20*, . . . ,20z can be a desktop 
or portable computer, each having at least one processing 
core 21a, . . . ,21*, . . . ,21z which can include a processor 
and memory. Each client node 20a, . . . ,20*, . . . ,20? 
accesses and maintains a respective local replicated database 
22a, . . . ,22*, . . . ,22z, each of which is replicated from the 
central database 12. As such, each of the client local data- 
bases 22a,. . . ,22*,. . . ,2 2z corresponds to a respective subset 
12a, . . . , 12*, . . . , 12z of the central database 12. 

As illustrated, server database subsets 12a, 12* can over- 
lap so that an individual data element in the server database 
12 can be present at a plurality of client databases 22a, 22*. 
Each of the client local databases 22a, . . . ,22*, . . . ,22z can 
also include additional data fields which are not related to 
data fields in the central database 12. 

In a particular preferred embodiment of the invention, the 
client-side databases 22a, . . . ,22*, . . . ,222 include tabular 
data which conforms to the Open Database Connectivity 
(ODBC) standard. Examples of suitable commercial prod- 
ucts include database products such as Microsoft Access, 
Watcom SQL, and Personal Oracle and spreadsheet products 
such as Microsoft Excel. Other tabular data storage struc- 
tures can also be used at the client. 

The server node 10 can preferably store data for all clients 
and support multiple simultaneous users, e.g., a mainframe 
computer or computer cluster. The client nodes 20 are 
preferably autonomous personal computers, such as laptop 
or hand-held computers, which intermittently communicate 
with the server node 10 through a communications network 
5, such as the telephone network. In general, although not 
required, the databases on the server and clients are hetero- 
geneous. As such the server cannot generally control the 
database semantics and operations at the clients. 
Furthermore, the server cannot rely on a knowledge of the 
database logic at the clients. 

As illustrated, each of the client nodes 20a, . . . , 20*, . . . , 
20z can establish a respective communication link 25a,. . . , 
25x, . . . £5z with the communications network 5, which is 
linked to the server node 10 through a communications link 
15. The communications links 15, 25 can be analog or digital 
links. To that end, each node includes a respective data 
transceiver 13, 23 such as an analog modem, a cellular 
modem, a digital (e.g., ISDN) modem, or an infrared (IR) 
transceiver. 

Over time, the central database 12 can be modified by 
users to insert, update and delete rows, columns and data 
fields. These modifications to the centra] database 12 can be 
accomplished by users at the server or by users at one or 
more of the client nodes 20. Similarly, a user at a particular 
client node 20* can also modify the client local database 22* 
over time by inserting, updating and deleting data fields. 
Because the client nodes 20 are typically disconnected from 
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the server node 10, corresponding data fields in the client groups can be defined which assure that synchronization of 

databases 22 and the central database 12 tend to diverge over a group of tables is treated as an atomic unit of work, 

time. FIG. 2 is a schematic block diagram of a client node 2(bc 

In general, only some of the data at the client and server having a client-side database synchronizer embodying the 

change over a period of time. The prior art approach of 5 invention. As illustrated in FIG. 1, the client node 20* 

propagating all data is therefore inefficient because data includes a processing core 21*, a local database 22* and a 

which has not been modified is transmitted to the server or cheat-ado database synchronizer 27*. The local database 

the client. Where the replicated databases are large, such an 2 A ^ mcl ^ de u S a pl ^ ahly °" ala ' ' V 22 ^ 

tU , . '. Although three tables are illustrated, it will be understood 

overhead noticeably slows down the synchronization pro- * 22x cm ^ ^ few a& Qne {M& 

cess. Further, the synchromzation process must often occur 10 ^ m ^ ^ ^ database synchronizer 

over communications channels that are sufficiently slow that 2Jx TOm rises a cliem catalog structure 60 * containing table 

transmuting more than the needed data imposes a hardship correspondences 60*-l, . . . ,60*-X and before-image logs 

oa users * 62x-l, . . . , 62*-X for each table 22*-l, . . . ,22*-X. Each 

The divergent data makes it difficult for the clients and table correspondence 60*-l, . . . ,60t-X includes an ordered, 

server to share data. That problem can be addressed by an ad 15 sequential listing of all of the replicated columns in each of 

hoc solution on the client-server network. Such solutions, the tables 22*-l t . . . ,22*-X of the local database 22x. Each 

however, are time consuming to develop, difficult to master, before-image log 62*-l, . . . ,62x-X corresponds to the last 

nongeneral in purpose, and suffer from various reliability synchronized values of the replicated columns in respective 

problems due to poor error recovery. lab i es 2 2*-l, . . . ,22*- X, of the local database 22x. 

A solution is therefore needed that minimizes the syn- 20 FIG. 3 is a schematic block diagram of a server having a 

chronization overhead. That task is made difficult because server-side database synchronizer 17 embodying the inven- 

the client-server platforms and databases are usually he tero- tion. As described above, the server node 10 includes a 

geneous. Adding to the challenge, the database structures at processing core 11 and a central database 12. In addition to 

client and server are, in general, different. Also, many communicating with the central database 12, the processor 

application situations allow for the same data item to be n communicates with the server-side database synchronizer 

updated at multiple sites. In those applications, such occur- 17. 

rences must be detected and handled on an exception basis The se rver-side database synchronizer 17 includes a 

so the data values do not diverge. catalog structure 70, a server update log 82, and a last 

A database synchronizer in accordance with the invention 3Q confirmed refresh table 84. The central database 12 is 

solves the prior art problem by defining a general purpose divided into replicated tables 12a, . . . ,12*, . . . ,12z. The 

database synchronization model in which a database devel- server catalog structure 70 includes a table correspondence 

oper provides a non-procedural description of the desired 72a, 72*, 72z for each replicated table 12a, . . . ,12r, . . . ,122. 

synchronization semantics. The description is compiled, the The server catalog structure 70 also includes entries 

needed information is stored at the server and each client, 35 75a, . . . , 75x, . . . ,75z corresponding to, and having 

and the synchronization run-time routines executing at both information about, client nodes 20a, . . . ,20*, . . . ,20z. There 

client and server synchronize the data based on the compiled is one server update log (SUL) 82a, 82*, 82z per table 

description. replicated from the central database 12. There is preferably 

A preferred embodiment of the invention provides for a one refresh table 84 for all data tables 12a, 12*, 12z. 

synchronization system which brings the client local data- 40 FIG. 4 is a schematic diagram of database table schemas 

base 22* into synchronization with the central database 12. implemented on the server node 10 and a particular client 

To facilitate the synchronization, a database synchronizer node 20* of FIG. 1. In the figure, columns which are 

17, 27 comprising programming instructions and data is commonly represented between multiple table schemas are 

resident on the server node 10 and client nodes 20, respec- indicated by the areas within the dashed lines, 

tively. During the synchronization process, database modi- 45 As illustrated, there is a table correspondence T which 

fications are propagated in both directions and conflicts are defines a key column K and non-key columns CI, C2, C3. 

detected and resolved so that data can be shared among a The table correspondence T is maintained on the server node 

plurality of nodes. The synchronization does not, in general, 10 and propagated to at least one client node 20. On the 

cause corresponding tables to become identical, because not server, the table correspondence T refers to a server table Ts 

all columns of the corresponding tables are replicated and 50 with columns Ks, Cls, C2s, C3s. On a client, the table 

some rows may be excluded from the synchronization correspondence T refers to a client table Tc with columns 

process by filters. Kc, Clc, C2c, C3c. The tables contain rows Rs, Rc selected 

A goal of a database synchronizer in accordance with the by a unique key value k stored in the key column Ks, Kc (i.e. 

invention is to minimize the cost of synchronization by Rs(k), Rc(k)). Although the key columns Ks, Kc are illus- 

reducing communication costs and delays in synchronizing 55 trated as single columns, the actual key may include multiple 

the databases. The database synchronizer is thus most effec- columns of information, such as a client tag and a sequential 

tive where the ratio of updated to non-updated data is counter, which together uniquely identify the row in the 

normally small. In addition, the database synchronizer is tables. Each table Ts, Tc is, in general, a subset of data stored 

efficient over relatively slow communication channels, such in the server database 12 and the client database 22*, 

as wireless connections, because minimal data is transferred 60 respectively. 

between the clients and the server. The client 20* includes a before-image log table lb 
A database synchronizer in accordance with the invention having rows Rb(k) and non-key columns Clb, C2b, C3b. 
manages replicated tabular data among a plurality of net- The value of the unique key value is stored in a key column 
e ro geneous computers that are usually disconnected from Kb. The before-image log table Th stores the last synchro- 
each other. The tabular data is preferably synchronized on a 65 nized data values for the client table Ts in the non-key 
per-table basis where the replica may be a horizontal or a columns Clb, C2b, C3b. FIG. 4 illustrates a case where all 
vertical subset of the source data. Preferably, transaction non-key columns are mutable. 
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The server 10 includes a server update log (SUL) table Tu insertion, the client must send values of all non-key col- 
having rows Ru(k,opt) and non-key columns Clu, C2u, C3u. umns. For an update, the client must send new values of all 
Each row is identified by the value of the unique key value updated non-key columns. The client does not send values 
k, which is stored in a key column Ku, and an ascendingly for columns that have not been modified. At step 125, the 
ordered operation timestamp (opt) for each key. The SUL 5 client uses the update operation to update befo re-image table 
table Tu records operations that have occurred for the server Th, making that row of the before -image table Th identical 
table Ts, The recorded information is maintained for each to the corresponding row of the client table Tc. At step 130, 
row of the server table Ts and includes an operation value the client node sends the table row message it has built to the 
(op) stored in an operation column OPu, the operation server node 10. 

timestamp (opt) for the operation stored in an operation 10 The database modifications included in the table row 

timestamp column OPtu, the numeric identifier (id) of the message can be" filtered at the client node 20* to keep rows 

node which performed the operation stored in an identifi- or columns of information in the client database 22* private 

cation column IDu, a refresh timestamp (rt) stored in a to the particular client node 2Qx. Column and row filtering 

refresh timestamp column (Rtu), and the values of the is accomplished when constructing each query on the client 

replicated non-key columns Clu, C2u, C3u of the server is table Tc and the before-image log table Tb. For column 

table Ts. The numeric identifier (id) is null if the modifica- filtering, only those columns specified as being updatable in 

tion on the server table Ts was not performed as the result the column list of the catalog table correspondence entry 60* 

of an operation propagated by a client node. The refresh are included in the query's selection. For row filtering, the 

timestamp (rt) is initially null and is updated during the filter predicate is included for restricting row selection. If 

client refresh process, as described below. 20 there are more rows to be compared in the client table Tc 

In addition, a refresh table Tr is maintained on the server (step 135), then processing returns to step 105. 

10. Each row of the refresh table Tr identifies a client C and As the before-image log table Tb is scanned for the above 

server table Ts, and records the time of the last refresh (rt) modification comparison, the values of the data fields are 

of the refresh table by the client C. passed to the checksum routine (step 105). Once the modi- 

FIGS. 5 A and 5B are flowcharts illustrating the major 25 fication comparison is complete, the calculated checksum is 

steps by which the client sends messages about database compared at step 140 with a stored checksum transmitted 

modifications to the server, and Lhe server processes those from the server node 10 after the last refresh (described in 

messages, in accordance with the invention. A client source detail below). If the data used by the client since the last 

routine 100 is illustrated in FIG. 5 A and a server destination refresh is valid, then the two checksum value must agree 

routine 200 is illustrated in FIG. 5B. A basic assumption for 30 (step 145) and synchronization can proceed. In this case the 

these figures is that the client and server were in synchro- client sends a commit message to the server (step 150). 

nization following the last refresh. Otherwise, a corrupt state has been detected and an error 

Referring to FIG. 5A, the server database synchronization message is sent to the server (step 155). 

is initiated by a particular source client node 20*. The client 35 Turning to FIG. 5B, the server node 10 receives the table 

propagates modifications of the client table Tc to the server row message from the client node at step 205. At step 210, 

by determining what has changed in the client table Tc since the server node performs a conflict check. When the server 

the last time modifications were propagated for the client processes the modifications in the table row messages sent 

table Tc. At step 105 the client adds each row of the by the client, the server may detect that a conflict has 

before-image log table Tb to a checksum that is accumulated 4Q occurred. Broadly speaking, a conflict occurs on a row when 

for later use. The source client node 20* does a row one or more data fields (columns) of the row change on both 

comparison between the client table Tc and the associated the client node 20* and the server node 10. In practical 

before-image log table Th by querying each table at step 110. terms, the client node 20* and server node 10 have changed 

If there is a difference (step 115), then there has been an the same piece of data — a given data field in a given row — to 

insertion, an update or a deletion of data fields in the row. 45 different values since the last time they were synchronized. 

The use of a before-image is only one way of detecting A conflict on a row R(k) exists if either of the following 

modifications at the client. The client can use one of many situations have occurred since the last refresh: 

other methods for determining the modifications since the 1. The row on the server Rs(k) and the corresponding row 

last synchronization. These other methods can include, but on the client Rc(k) have been separately updated to 

are not limited to, DBMS logging and application logging to 50 different values, even if the updated columns are dis- 

create a client update log table similar to the server update joint. For example: 

log table Tu. To be general purpose and compatible with a. The same column at the server and the client can both 

heterogeneous database products, the database synchronizer change to different values. This results in a direct 

requires a general purpose technique. Because many com- column conflict that must be settled by selecting one 

mercially available client database products currently lack 55 value and discarding the other, 

logging capabilities, a preferred embodiment of the inven- b. Different columns can change at the server and 

tion employs the before-image technique. client. This results in a conflict that can be resolved 

At step 120, the client node 20tr builds a table row without discarding either value, 

message to be transmitted to the destination server node 10. 2. A row R(k) has been updated in one place (client or 

For each changed row Rc(k) of the client table Tc, the client 60 server) and deleted in the other. In effect, each updated 

sends a message to the server describing an operation, which column of the row that still exists is in conflict with the 

can be an insert (I), an update (U) or a delete (D) operation. non-existent column of the non-existent row in the 

When using the before image change detection technique, it other location. 

is assumed that for any row Rc(k), the client sends at most 3. A row R(k) did not exist at the time of the last refresh 

one message per update propagation. For any operation, the 65 and row R(k) has since been inserted (and possibly 

client sends the value(s) of the key column(s). For a deletion, updated) in both places and the server row Rs(k) is not 

no further information is sent about the row Rc(k). For an equal to the corresponding client row Rc(k). 
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If a conflict is detected (step 215), then the server node 10 
performs processing steps to resolve the conflict at step 220. 
When a conflict has been detected, it must be resolved if the 
tables are to return to a synchronized state. During conflict 
resolution, a detected conflict is resolved in favor of the 
client or server, depending on information stored in a table 
correspondence, which is preferably defined for each table in 
the server catalog 70. If the conflict cannot be resolved in 
this automatic fashion, it must be resolved manually. 

In a preferred embodiment of the invention, the server 
node 10 weighs in favor of either the current value in the 
central database 12 or the updated value from the updating 
client node 20*. For specific data fields, the server node 10 
can resolve database conflicts in favor of some client nodes 
but not other client nodes. Further details of the conflict 
resolution process are described below. 

If the conflict is resolved in favor of the client (step 225) 
or if there is no conflict, then at step 230, the server node 10 
modifies data in the central database 12, and a record of the 
client's operation, including the client's numeric identifier, 
is added to the server update log at step 235. For additional 
rows (step 240), processing returns to step 210. 

FIGS. 6 A and 6B are flowcharts illustrating the major 
steps by which the server computes and sends table modi- 
fication messages to the client in accordance with the 
invention. This is called "refreshing the client." A client 
destination routine 300 is illustrated in FIG. 6 A and a server 
source routine 400 is illustrated in FIG. 6B. 

Gient database synchronization is initiated by the desti- 
nation client node 20x, at step 305 of FIG. 6A, where a table 
refresh request message is transmitted to the source server 
node 10. The table refresh request message is received by the 
server node 10 at step 405 of FIG. 6B. The server node 10, 
at step 410, determines the refresh data to return to the client 
node 20* by querying the server update log table Tu. As the 
refresh data is determined for each row, a table row refresh 
message is built at step 420. At step 425, the table row 
refresh message for the replica database is transmitted to the 
client node 20x. If there are more unique rows in the SUL 
query result at step 430, then processing returns to step 415. 
As above, only the data field values to be updated at the 
client node 20* are transmitted. 

At step 435, the server calculates a checksum value and 
sends it to the client. The checksum is calculated on the rows 
of the server table Ts after applying the client filter and 
excluding columns not replicated at the client. The server 
also transmits a refresh timestamp to the client in this 
message. 

Returning to FIG. 6 A, each table row refresh message 
from the server node 10 is received by the client node 20* 
at step 310. For each row R(k) received from the server 10, 
the corresponding row Rc(k) of the client table Tc is updated 
at step 315. The before-image log table Tb is updated at step 
320, making that row of the before-image log table Tb 
identical to the corresponding row of the client table Tc. If 
more table row refresh messages are available at step 325, 
then processing returns to step 310. Otherwise, processing 
continues to step 330, where the server checksum value and 
timestamp arc received, and then to step 335, where the table 
checksum value from the server node 10 is stored for later 
use by the client node 20* to validate the working data in the 
client table Tc. 

At step 340, the client node 20* transmits a refresh 
acknowledgment message to the server node 10 to acknowl- 
edge a successful refresh. The refresh acknowledgment 
message includes the refresh timestamp received by the 
client at step 330. The client node 20* may, however, accept 
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or reject the refresh data from the server node 10. The client 
node 20* is now free to disconnect from the server 10 or to 
process additional tables. 

Returning to FIG. 6B, the refresh acknowledgment mes- 
sage is received by the server node 10 at step 440. At step 
445, the refresh table Tr is updated with the received 
timestamp. 

Generally, but not necessarily, the client node 20* 
executes a script which propagates its modifications to the 
server node 10 for a given table before requesting that the 
server node refresh that table. It is possible for the client to 
propagate its modifications without requesting a refresh. 
However, for any refresh messages to be applied to the client 
table Tc, the client table Tc and the before-image log table 
Tb must have identical data. This implies that all current 
updates for a table T must be propagated to the server before 
a refresh request can be sent. Furthermore, refresh messages 
cannot be applied at the client for table T if any modifica- 
tions had been made to the client table Tc since that last 
propagate. 

In the simple case, the client requests a refresh on the 
client table Tc immediately following each propagation of 
modifications for the client table Tc; thus, the time of last 
propagation coincides with the time of last synchronization. 
However, the client may propagate modifications without 
requesting a refresh. The server conflict detection algorithm 
takes this possibility into account. 

For various reasons, the client table Tc and the server table 
Ts may not get correctly synchronized. Erroneous synchro- 
nization can be caused by misuse of internal tables, misuse 
of internal control constructs (e.g., triggers), or simple 
corruption of data. The situation can also occur due to bugs 
in the synchronization software. When this happens, the 
users are notified so the problem can be corrected and so that 
data does not diverge further. 

In cases where the amount of data is large compared to the 
bandwidth of the connection between the two nodes, check- 
ing collections of data to determine whether they are iden- 
tical is typically done by generating checksums at both sites 
and comparing the checksum values. If the checksum values 
are different, there is a problem. If the checksum values are 
the same, the data is probably the same because the prob- 
ability of a false negative is very low where an appropriate 
checksum algorithm is used. A checksum comparison tech- 
nique is preferable to performing a full comparison of the 
data because the latter requires that all data be copied from 
one node to the other where the full comparison can take 
place. Because of the bandwidth, which may be very low 
relative to the amount of data to be compared, e.g., if a 
wireless modem is used, and the usually slow speed of the 
client node, which may use a slow hard drive driven by a 
slow CPU, checksum techniques are more appropriate than 
full comparisons. 

Although users should validate the synchronization fre- 
quently (ideally every time a table refresh operation is done), 
they may not do the validation unless the overhead is very 
low, especially at a slow client where performing an extra 
checksum generation pass over the data can impose an 
unacceptable overhead for many users who may, therefore, 
simply not validate the synchronization. 

To minimize the number of passes over the data, the 
checksum calculations are preferably performed when the 
database synchronizer is reading data anyway (as part of the 
normal synchronization process). The normal process for 
synchronizing a client table Tc and a server table Ts uses a 
three-step process. First, software at the client determines 
what updates to the client table Tc have taken place since the 
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last refresh. The client does this by comparing the client 
table Tc with the befo re-image table Tb. The before-image 
table Tb is effectively a copy of the table as of the last time 
it was synchronized. Second, the updates are propagated to 
the server, which has determined what changes have taken 5 
place to the server table Ts since the last refresh. Finally, the 
server detects update conflicts, resolves them, and propa- 
gates updates back to the client as refresh data. It is only at 
this time, immediately after the completion of 
synchronization, that the tables are consistent; that is, the 10 
value of shared data at the server when it completes trans- 
mitting refresh messages should be identical to the value of 
shared data at the client immediately after it completes 
processing of the refresh messages. 

At first, one might believe that the client -side checksum 15 
can be efficiently derived during the first step data pass, 
passing the already-read data from the client table Tc to the 
checksum routine. Unfortunately, this does not work 
because the data in the client table Tc can be further updated 
as part of the synchronization process. Instead it would be 20 
logical to calculate the checksum immediately after the 
refresh, but this has the disadvantage that it requires an extra 
pass over the client table Tc, substantially increasing the 
time it takes to perform synchronization processing at the 
client. 25 

Instead of generating a checksum from the client table Tc, 
a checksum is generated from the before-image table Tb. As 
described above, the first step at the client includes scanning 
all before-values anyway (to determine what changed). Each 
value from the before-image table Th is then passed to the 30 
checksum routine as it is being read. The result is a check- 
sum that should match what the server data looked like 
immediately following the previous refresh pass. 

As part of each refresh pass, the server sends a checksum 
for its replica of the data. The client saves the checksum 35 
value and uses it the next time it is scanning the before- 
image table (for a refresh or propagate updates operation). If 
the checksums do not match, the server is notified, the 
modification messages generated during the first step are 
discarded, and the client is marked and disabled to await 40 
intervention. Thus, an extra pass over the client data is 
avoided. 

At the cost of the extra pass, it is possible to notify the 
client of inconsistencies immediately upon completion of 
the synchronization, rather than "late notification" resulting 45 
from waiting until initiating the next synchronization. 
However, the approach of detecting the problem during the 
next synchronization process is not harmful to the database 
because it does not result in the loss of any information. 
There is still sufficient information to determine the contents 50 
of the non-matching client and server tables. It is true that 
some additional updates may have taken place at the client 
or server, but these are all identified and available for 
reconstructing the desired matching state. Indeed, even if the 
less efficient (extra pass) algorithm were used in which the 55 
client checksum was computed immediately after the 
refresh, it is generally the case that further updates have 
occurred at the server. Essentially, there is no way to prevent 
updates at the server following synchronization (i.e., there is 
no way to prevent some degree of "late notification") in any 60 
event. 

FIG. 7 is a schematic diagram of a table row message. The 
table row message 50 includes a message header 52 and a 
body 54. The header 52 contains the message code which 
identifies the message as either an insert, an update or a 65 
delete operation. The body 54 preferably includes a key field 
55 for the unique key value identifying the table row in a 



relational database, a column identification field 57 for 
identifying the column(s) at which the modified data field(s) 
reside(s) and a stream of data values 59 which are the 
modified data values from the replicated database 22*. Each 
updated value occupies a respective subfield of the stream 
59. There is a separate message for each modified row and 
each field in the message is preferably byte -aligned. A 
compression algorithm can be used during transmission of 
the message to further reduce the length of the message and 
thus the connect time. 

The data values 59-1, . . . ,59-n can be the actual new 
values of the updated data fields; compressed representa- 
tions of these values; or instructions, such as edit strings, for 
converting the old values to the new values. The mechanism 
of transmitting the values can be selected on a column-by- 
column basis. 

The column identification field 57 can be implemented 
using a bit-map or a stream of index values. The choice as 
to which to implement depends on the total number of 
columns in the table and the number of updated columns. 
These factors contribute to the overhead of sending the 
identifying information. 

The decision as to which method of identifying the 
columns to use is preferably done dynamically, based on the 
message being sent. For simplicity, however, a choice can be 
made based on the nature of the tables being replicated. In 
general, the bitmap method is more appropriate where at 
least Vath (rounded up) of the total number of columns are 
updated. The bitmap method is always more appropriate 
where the table has 8 or fewer columns. By dynamically 
choosing an identification method, each message can be 
built having the minimum number of 8bit bytes necessary 
for communicating the message semantic. 

As illustrated there are n subfields of data values indicated 
by reference numerals 59-1, . . . ,59-n. The size of each 
subfield in the stream 59 is determined by the type of data 
stored at the respective position in the replicated database 
table 22*. In the preferred embodiment of the invention, the 
table row message 50 indicates individual data fields in the 
replicated row of the database table 22* and each subfield of 
the data stream 59 corresponds to the modified value of the 
indicated data field. It is important to note that only the 
current values of inserted or updated data fields are trans- 
mitted from a client to a server. Previous values are never 
sent. 

The following lists the messages preferably used to imple- 
ment the database synchronizer's communication protocol 
between the client and server nodes: 

Begin-Task 

End-Task 

Begin-Transaction-Group 

End-Transaction-Group 

Insert 

Update 

Delete 

Table-Refresh-Request 

Full-Table-Refresh-Request 

Begin-Table-Refresh 

End-Table-Refresh 

Task-Complete 

Error 

Client-Refreshed 

The steps in a synchronization are described by a 
sequence of operations called a task. The following grammar 
describes the message protocol of messages transmitted 
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from the client to server. Id the grammar, items which are not 
enclosed in angle brackets (<>) represent messages. 



<task> :: - Begin-Task <lask_body> End-Task 
<lask_body> :: - <task_element_list> 

<task_elemenl_list> :: - <task_elemeat> <task_e!ement_list> 
<task_element_list> :: - <null> 
<task_element> - <lable_ope ratio n_list> 
<task_clement> :: - <transaction_group> 

<table_ope ration list> :: « <tab_op_iist> <re fresh request> 

<tab_op_list> :: » <tab_op> <tab_op_list> 

<tab_op_Iist> :: = <null> 

<tab_op> :: = <row__op> 

<tab_op> :: = Commit 

<row_op> :: = Insert 

<row_op> :: - Update 

<row_op> :: - Delete 

<re£resh_request> :: = Table-Refresh-Request 
<refresh_requesl> :: = <nuJl> 
<transaction_group> :: ■ 

Begin-Transaction-Group <transaction_body> 

End-Transaction-Group 
<transaction_body> :: - <trans_op_list> <refresh_req_list> 
<trans_op_list> :: - <row_op> <trans_op_list> 
<trans_op_list> :: = Commit 
<refresh_req_1ist> :: - <ref_req_ltst> 
<refresh_req_list> :: » <null> 
<ref_req_list> 

Table- Refresh- Request <ref_req list> 

<ref_req_list> :: = Commit 
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Similarly, the message protocol for messages sent from 
the server to the client for refreshing the client is as follows: 



<task_refresh> :: *» <refresli list> Task-Complete 

<refresh_list> :: = <refresh transaction <refresh_list> 

<refresh_list> :: = <null> 

<refiesh_transaction> :: = <table_refresh_list> Commit 
<table refresh list> :: = 

<table_refresh_> <table_re fresh _Jist> 
<table_refresh_list> :: = <nu!l> 
<table_refresh>:: - 

Begin-Table- Re fresh <ref_op_list> End-Table- Re fresh 
<ref_op_Iist> :: - <row_op> <ref_op_list> 
<ref_op_list> :: - <null> 



35 



40 



Error messages can occur at any time and are handled in 
context. They are used to communicate an error situation at 
either the client or server and trigger the appropriate error 
recovery. 45 

The Insert, Update, and Delete messages communicate 
data modifications. The Commit message is used to indicate 
transactional semantics. The Table -Re fresh-Request mes- 
sage causes the server to synchronize the indicated table at 
the requesting client. All other messages are used for context 50 
and sequencing error checks. 

EXAMPLE 

FIGS. 8A and 8B are schematic diagrams illustrating table 
12a in a central database 12 and an exemplary table 22*-a in 55 
a client database 22x, respectively. The central database 12 
and the client database 22x include tables organized in rows 
and columns of data fields, which are initially synchronized 
as shown. The values of the non-key data fields are illus- 
trated by reference characters A-V. Also shown are the key 60 
columns K 12 , K^ 2 and the unique key values stored therein. 

As illustrated, the first row Rl^ of the client table 22x-a 
is a replicated subset of the first row Rl 12 of the central 
database table 12a. The second row R2 22 of the client table 
22x-a is a replicated, subset of the fourth row R4 J2 of the 65 
central database table 12a. Only the first, second and fourth 
columns Cl 32 , C2 12 , C4 J2 of the central database table 12a 



are replicated to the columns Cl^, C2 22> C3 22 of the client 
table 22*-a. The client table 22jc-a also includes a fourth 
column C4 22 which does not correspond to any column in 
the central database table 12a and a row R3 22 which does not 
correspond to any row in the central database table 12a. 

A table correspondence entry exists in the replicated 
catalog 60x for each replicated table and describes the 
corresponding client and server tables and replicated col- 
umns. The information as to which columns are replicated is 
included within a table correspondence entry in the repli- 
cated catalog. Likewise, filters used to specify which rows 
are shared between the client and central copies of a repli- 
cated table are also included in the table correspondence 
entry in the catalog. 

FIGS. 9 A and 9B are schematic diagrams of a table view 
of a replicated server-side and client-side database table, 
respectively. As illustrated, the server table view Ts is a 
filtered subset of the central database table 12a. Likewise, 
the client table view Tc is a filtered subset of the client 
database table 22x-a. The table correspondence describes 
which columns of tables 12a and 22jc-a appear in these 
views, and the filters in the table correspondence provide 
predicates that must be satisfied for rows to appear in the 
views. 

For clarity and ease of description, only rows common to 
the server table Ts and the client table Tc are shown in the 
figures. As illustrated, both the server table Ts and the client 
table Tc have two common rows, each having a unique key 
value. In the illustrated example, the rows for key values "1" 
(i.e., R(l)) and "4" (i.e., R(4)) are replicated at the client. 

Likewise, only columns defined by the table correspon- 
dence as being shared columns are shown in the figures. 
Each computing node uses table correspondences stored in 
its catalog to filter column data from the databases. 

FIGS. 10A and 10B are schematic diagrams of the client- 
side catalog and before-image log table, respectively, for the 
server table Ts of FIG. 9 A. The client-side table correspon- 
dence Lc is an ordered, sequentially-indexed list of the 
columns of the client table 22x-a which are replicated to the 
client table view Tc. The associated before-image log table 
Tb provides a reference from which changes to the client 
database table Tc are measured. As an initially synchronized 
database, the before-image log table lb is identical to the 
client-side updatable columns of client table Tc of FIG. 9B. 

FIGS. 11 A, 11B and 11 C are schematic diagrams of the 
server-side table correspondence Ls, server update log table 
Tu, and refresh table Tr for the server table Ts of FIG. 9B. 
The server-side table correspondence Ls is an ordered, 
sequentially-indexed list of the columns in the central table 
12a which are replicated in the client table Tc. There is a 
one-to-one correspondence between the index into the 
server-side table correspondence Ls and the respective 
client-side table correspondence Lc. 

The server update log table Tu for the server table Ts 
records information about operations that have been per- 
formed on the server table Ts. The operation column OPu 
can have a value representing the insert (I), update (U) or 
delete (D) operation. In the SUL table Tu, the values stored 
in the non-key columns Clu, C2u, C3u depend on the 
recorded operation. If the recorded operation is an update or 
a delete, then the values of the non-key columns contain the 
values from the server table Ts immediately preceding the 
operation (i.e., before values). If the recorded operation is an 
insert, the values of the non-key columns contain the values 
of the server table Ts immediately after applying the insert 
(i.e., inserted value). When the server 10 applies a client 
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update to the server table Ts, the identifier ID is set; 
otherwise the identifier is not set (i.e., it is null) to indicate 
a modification by some means other than the server applying 
a client operation to the server table Ts. 

As illustrated in FIG. UB, the operations recorded on the 5 
SUL table Tu are all insertions. The operation timestamp 
column OPtu has time values indicating the time of 
insertion, tO. The client identifier column is null to indicate 
an insertion by other than a synchronized client. The values 
of the non-key columns Clu, C2u, C3u reflect the inserted 10 
values. 

The refresh table Tr of FIG. 11C reflects the time at which 
the server table was confirmed to be refreshed by the client 
nodes 20. Here, the replicated client table Tc is represented 
as being refreshed at the client nodes 20a, . . . ,20*, . . . ,20z 35 
at times t0 fl , . . . ^0^, . . . ,t0^, which are the times at which 
the server table Ts and the client tables Tc were initially 
synchronized. 

FIGS. 12 A and 12B are schematic diagrams of a modified 
server table Ts and an updated server update log table Tu, 20 
respectively. Note that the server table Ts has been modified 
since the last synchronization. As illustrated, the data fields 
Rs(l)Cl and Rs(4)Cl of the server table Ts have changed 
from the initial values in FIG. 10B. As represented in the 
SUL table Tu, the data fields were updated by client nodes 25 
20a and 20z, at time tl and t2, respectively. Since these were 
update operations, the data fields of the SUL contain before - 
values A and M, not new values A' and M'. 

FIG. 13 is a schematic diagram of a modified client table 
Tc. As illustrated, the data fields Rc(l)Cl and Rc(4)C3 of the 
client table Tc have changed from the values initially in FIG. 
10A. At an arbitrary time t3, the client connects to the server 
to propagate the modifications of the client table Tc to the 
server. 35 

FIG. 14A and 14B are schematic diagrams of table row 
messages from the client node 20* to the server node 10 for 
the modifications illustrated in FIG. 12 A. As illustrated, the 
column identification field 57 is a one byte bit-mapped field 
because there are only three columns in the table R. Each bit 40 
bl. . .b8 represents an index position in the client-side table 
correspondence Lc. As illustrated, the first bit bl of the field 
corresponds to the first index position in the client-side table 
correspondence Lc and the third bit b3 corresponds to the 
third index position in the client-side table correspondence 45 
Lc. Bits four through eight are not used, so they are cleared. 

As illustrated in FIG. 13, the initial data field values of A 
and P have been updated to A" and P" respectively. 
Consequently, the key values for the two changed rows must 
be passed in the message. In FIG. 14A, the key field 55 is 50 
set to a value of "1". In FIG. 14B, the key field 55 is set to 
a value of "4". The first and third positions in the client-side 
table correspondence Lc are marked in the column identi- 
fication field 57 at the first bit position bl in FIG. 14A and 
the third bit position b3 in FIG. 14B. The value field 59 55 
includes the updated values from the corresponding data 
fields. As illustrated, the value A" is in the first (and only) 
value field 59-1 in FIG. 14A and the value P" is in the first 
(and only) value field 59-1 in FIG. 14B. 

Conflict Detection and Resolution Processing 60 

As illustrated, there is one conflict in the databases, which 
is detected by the server 10 upon receipt of the update 
messages from client 20*. Specifically, the change to the 
data field R(1)C1 is in conflict with the change previously 65 
made by client 20a. The conflict is resolved at the server 10 
and the central database table \2a is updated. 
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For a server row Rs(k), the server update log table 1\i 
records a series of M operations (Ru(k(l. . .M),opt):op that 
have been carried out on that row since the last time a client 
was refreshed, A Server Effective Operation (SEO) is 
defined as the single operation that yields the same result as 
a series of operations on a row. For example, an insert 
followed by an update is effectively still an insert and an 
insert followed by a delete is effectively a non-operation 
(No Op). A server effective operation of "NoOp" means there 
has been no effective operation on the row R(k). For 
example, if a row Rs(k) on the server was inserted, then 
deleted, since the last refresh, that row will never be seen by 
the client. 

A client's be fore -values are its values for non-key col- 
umns of the row Rc(k) on the client at the time it last 
propagated an update or a delete on that row Rc(k) to the 
server. If a client has not propagated modifications since the 
last time it was refreshed, then the before values can be 
determined by taking column values from the first SUL entry 
for the row R(k) following the time of the last refresh. 
However, a client may propagate modifications multiple 
times before it is refreshed, accepting that it will be out of 
synchronization during this time. This fact complicates the 
determination of both the server effective operation and the 
client's before values. 

The server effective operation may be affected by inter- 
mediate modification propagation. The server effective 
operation must be determined with respect to the client 
propagating the modifications. If the client sends an inter- 
mediate operation such as a delete that puts it into synchro- 
nization with the server, the server effective operation 
becomes a No Op, because client and server agree at that 
point; if some other client sent the same operation, the server 
effective operation instead becomes a delete. 

Similarly, intermediate modifications change the server's 
picture of the client's before values by showing how those 
values have changed since the last refresh. For example, if 
the client has propagated an intermediate update on a row 
R(k), the change in the update needs to be applied to the 
server's picture of the client's before values. 

The server effective operation and before values are 
determined by selecting the SUL entries for the row R(k) 
since the last refresh, ascendingly ordered by the operation 
timestamp. A provisional-before-values (pbv) list is created 
that is initially empty, and a provisional Server Effective 
Operation (pSEO) is created that is initially NoOp. The SUL 
entries are then iteratively read, using Table I below to 
determine a new pSEO and pbv at each entry. At each 
iteration, the notation Ru(k(m)):cv indicates the column 
values in the current SUL entry; and the notation Ru(k(m+ 
l)):cv indicates either the column values from the next SUL 
entry, or the column values from the server row Rs(k) if 
there are no more SUL entries. The column headings in 
Table I indicate the following: 

i) pSEO(m-l) is the value of the provisional SEO at the 
start of this iteration. 

ii) Ru(k(m)):op is the operation seen on this iteration. 

iii) Ru(k(m)):id="x" is "Yes" if client x (the client for 
which the SEO is being determined) performed the 
operation seen on this iteration and "No" otherwise. 

iv) pSEO(m) is the value of the provisional SEO at the 
end of this iteration. 

v) pbv(m) is the value of the provisional before-values for 
client "x" at the end of this iteration. 
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TABLE I 



pSEO(m - 1) 


Ru(k(m)):op 


Ru(k(m)):id - _ x" 


pSEO(m) 


pbv(m) 


Notes 


NoOp 


Insert 


Yes 


NoOp 


Ru(k(m)):cv 




NoOp 


Insert 


No 


Insert 


pbv(m - 1) 


No change 


NoOp 


Update 


Yes 


NoOp 


Ru(k(m + l)):cv 


A pSEO of NoOp 



NoOp 



Update 



Update 



NoOp 
NoOp 



Delete 
Delete 



Yes 
No 



NoOp Empty 
Delete 



Insert 



Insert 



Insert Yes/No 



Update Yes 



Impossible 



NoOp Ru(k(m + l)):cv 



Insert 
Insert 



Insert 
Update 



Update 



Update 
Delete 



Delete 
Insert 



Update 



No 
Yes 



No 

Yes/No 



Yes 



Insert pbv(m - 1) 
Impossible 



NoOp pbv(m - 1) 
Impossible 



Update pbv(m - 1) + change 



indicates 
Rs(k) - - Rc(k) at 
the time this 

client does this update, so 
the pbv is assigned from the 
next SUL entry, which 
contains the values resulting 
from this update and 
therefore the client*s values 
at the time it sent the 
update. 

If this is the first SUL 
entry, pbv is set to 
Ru(k(m)):cv, otherwise, the 
pbv does not change. (An 
operation of Update or 
Delete means that Rc(k) 
existed as of the last refresh, 
so its initial values are in 
the first SUL entry 
following that 
time.) 

If this is the first SUL 
entry, pbv is set to 
Ru(k(m)):cv; otherwise, the 
pbv does not change. (An 
operation of Update or 
Delete means that Rc(k) 
existed as of the last refresh, 
so its initial values are in 
the first SUL entry 
following that time.) 
This would indicate 
insertion by the client of a 
record that already exists, 
because it was inserted or 
updated previously. 
An insert conflict that is 
decided in favor of the 
client is implemented by 
updating the 
server's record, 
resulting in this 
entry and 

changing the SEO to NoOp. 
No change 

This client cannot be trying 

to update or delete because 

it cannot possess the record, 

otherwise the pSEO would 

not be Insert. 

No change 

This would indicate 

insertion by the 

client of a record 

that already 

exists, because it 

was inserted or updated 

previously. 

If the record has been 
previously updated and this 
client is doing an update, 
the column(s) changed by 
this client must be 
determined and those values 
merged into the current pbv. 
The changed value (s) are 
found by comparing 
Ru(k(m)):cv to 
Ru(k(m + l)):cv, 
noting what has 
changed (these 
are the client's changes) and 
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TABLE I-continued 



pSEO(m - 1) Ru(k(m)):op Ru(k(m)):id - "x" pSEO(m) pbv(m) Notes 













merging the changes into 












pbv. 


Update 


Update 


No 


Update 


pbv(m - 1) 


No change 


Update 


Delete 


Yes 


NoOp 


Empty 




Update 


Delete 


No 


Delete 


pbv(m - 1) 


No change 


Delete 


Insert 


Yes 


NoOp 


Ru(k(m)):cv 




Delete 


Insert 


No 


Update 


Pbv(m - 3) 


No change. An effective 
Delete followed by Insert 
results in Update, 
not Insert. This 
is the same 
approach used by 
the client source in 
determining what updates to 
propagate; it only has the 
be fore- image and the current 
database, with no record of 
intermediate operations. 


Delete 


Update 


Yes/No 


Impossible 




A pSEO of Delete indicates 
that Rs(k) does not exist, so 
it cannot be deleted or 
updated. 


Delete 


Delete 


Yes/No 


Impossible 




A pSEO of Delete indicates 
that Rs(k) does not exist, so 
it cannot be deleted or 
updated. 



In a potential conflict situation, the client operation and 
the server effective operation determine what sort of conflict 
may have occurred. Table II below summarizes the possi- 
bilities. Note that three of the "impossible" situations can 
occur if a previous client operation (CO) is rejected due to 
a conflict - these are: SEOUpdate, CCMnsert; SEO=Insert, 
COUpdate; and SEOInsert, CO=Delete. 

TABLE II 



Server 
Effective 



Client Operation 



Operation Insert 



Update 



Delete 



Insert 



Update 



Insert conflict: 
Client and server 
are trying to insert 
the same record 
with different 
non-key values. 
Impossible. 



Delete Impossible. 



Impossible. 



Update conflict: 
Server and client 
are trying to up- 
date same columns 
of same record to 
different values. 
Delete conflict: 
Server is trying to 
delete the same 
record the client is 
trying to update. 
Resolution is on 
row basis. 



Impossible. 



Delete conflict: 
Client is trying to 
delete a record 
that server has 
updated 

No conflict. 



Only conflicts in which columns are in direct conflict arc 
detected. These include insert conflicts in which one or more 
fields of the inserted rows are different; all delete conflicts; 
and update conflicts in which one or more fields of the 
update rows have been changed to different values. It is 
possible, however, to detect update conflicts in which data 
fields are not in direct conflict, by comparing the client's 
before-values to all non-key data fields, not just those 
contained in the client update message. 
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Conflict Resolution 

When the server detects a conflict, it falls into one of three 
categories shown in Table II: an insert conflict, in which 
client and server insert the same row but with different 
non-key values; a delete conflict, in which one system 
deletes a row the other updates; and an update conflict, in 
which client and server update one or more corresponding 
35 data fields to different values. The catalog structure contains 
information on how to resolve each of these conflicts for a 
table correspondence. 

For insert conflicts and delete conflicts, the catalog 
instructs the server to select either the client's operation or 
40 the server's operation, and to reject the other operation. For 
an insert conflict, either the client's complete row or the 
server's complete row is inserted. For a delete conflict, the 
row is either deleted, or the complete set of updates is 
applied. 

For update conflicts, the catalog instructs the server to 
select either the client's value or the server's value for each 
individual conflicting data field. For example, the catalog 
can state that for columns CI and C3, the server value 
prevails, but for column C2 the client value prevails. 

The server uses the conflict resolution settings in the 
catalog to determine whether to apply the client's changes to 
the server table. For cases where the client operation or 
updated data field value prevails, the server applies the client 
operation or update. For cases where the server operation or 
updated data field prevails, the server does not apply the 
client operation or update. In these cases, the client table will 
not agree with the server table until the client is next 
refreshed. 

When a client operation is rejected during conflict 
resolution, the server places special entries in the server 

60 update log so the client is sent correct instructions the next 
time it is refreshed. This is necessary because the server 
update log otherwise would not include a correct picture of 
the state of the client table, because it includes no record of 
the client's rejected operation. The special entries are iden- 

65 tified by the identifier of the client whose operation was 
rejected. They are: Send-Insert (S-I), and Send- Update 
(S-U). 
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The Send-Insert entry instructs the server to send the client, only those row-column values that are different 

client an insert message with the server's current values the between the server 10 and the client 20x are sent to the 

next time the client requests a refresh. The Send-Update client. That task, however, is complicated by filters at the 

entry instructs the server to send the client an update server 10 which filter out rows that should not be stored at 
message with current values for all data fields the next time 5 the clicnt 2ft * F° r example, changes to column values that 

the client requests a refresh. Following conflict resolution, a PP ear in filter can ™ usc rows t0 be filtered into the 

the server inserts these entries in the server update log as refresh message and others, that previous to the change were 

described below replicated at the client 20*, to be filtered out of the refresh 

For an insert conflict in which the server prevails, the rnessage. 

, o j it j * . • .u j * i in A preferred embodiment of the invention uses a smart 

server places a Send-Update entry in the server update log io ^ ^ to ^ ^ 

The server also places a Send-Update entry when the cheat a minimum £ t of cliem effective operations needed to 

and server insert identical rows. If the server update log did synchronize a client are calculated based on a knowledge of 

not include this entry, the server would send the client an updates made t0 the ^ table Ts since the last refresh of 

insert message mstead of an update message, causing the me client. This minimum set of client effective operations 

client to try to insert a row that already exists and resulting 15 for the refresh are then sent tQ the ciient m a fefresh messaget 

in an error. j 0 de termine the set of client effective operations, the 

When the client deletes a row, the server updates it, and server must first determine which rows have changed in the 

the server operation prevails, the server places a Send-Insert server table since the last time the client was refreshed, 

entry in the server update log. If the server update log did not Using the last-refreshed time from the refresh table Tr, the 

include this entry, the server would send the client an update 20 server selects from the SUL table Tu all those rows having 

message instead of an insert message, causing the client to a refresh timestamp Rtu that are later than the last-refreshed 

try to update a row that does not exist and resulting in an time or are null, ordering by the server key column Ks, then 

en" 0 *"- by the operation timestamp opt. This results in groups of 

When the client and server both delete the same row, it is records that describe operations on the server table Ts that 

not a conflict, but the server needs to know that the client has 25 have not been seen by the client 20*. Each group of records 

also deleted the row so as to not send the client a delete for a specific value of the server key column Ks describes 

message. The server places a Send-Insert entry in the server operations that have occurred on the corresponding row of 

update log. If, at the time of next refresh, the row does not the server table Ts. The use of the refresh timestamp Rtu to 

exist in the server table, the server will send no message to select rows from the SUL is explained below, 

the client. If on the other hand the row exists because another 30 For each such group of records, the server determines the 

client has inserted it at the server, the server will send an Server Effective Operation (SEO) and client before values as 

insert message with the current row values to the client. described above. However, in addition to the four types of 

To assure that conflicts do not occur due to non-unique SEO described above (Update, Insert, Delete, and NoOp) the 

keys, any of several mechanisms can be used to assure that 35 server may detect an SEO of Send-Insert or Send-Update. 

the row keys are unique across the computing system. As This occurs if a previous operation from client 20* resulted 

described above, a sequential key value can be tagged with in a conflict that was resolved for the server, or if the server 

the identifier of the creating computer (server or client). and client 2Qx inserted identical rows or deleted the same 

Alternatively, the server and the clients can each be assigned row. The presence of Send-Insert or Send- Update in the 

arbitrary key values or a range of key values. Other suitable 4Q SUL affects the calculation of the Server Effective Operation 

techniques can also be used. The choice of which technique as shown in Table III below, which is an extension of Table 

to use on a computing system is selected by the designer of I. 
the synchronized application. 

FIGS. 15A and 15B are schematic diagrams of an updated TABLE III 
server table Ts and an updated server update log table Tu, 45 
respectively. The update to data field Rs(4)Cl of the server 
table Ts is used to update the corresponding data field 
Rc(4)Cl of the client table Tc. As illustrated, the conflict 
over the data field Rs(l)Cl has been resolved in favor of the 
value from the server table Ts. The new entries in the server 
update log table Tu reflect changes to the rows of the server 
table Ts due to the change data propagated from the client 
table Tc of the client node 20*. Because there has been no 

refresh of the client table Tc, the refresh table Tr of FIG. 11C In effect> the Send-Insert and Send-Update operations 

is unchanged with respect to this client node 2<k. ss as signals which the server records for its own use 

Refresh Mechanism Processing durin S detectioQ and resolution. These signals are 

not actually modification operations. The Send-Insert and 

For each row of the server table Ts, the server determines Send-Update signals are useful when (l) the server rejects a 

a Client Effective Operation (CEO) to be sent to the client client operation in favor of a conflicting server operation and 

node 20x at step 415. The client effective operation is based 60 (2) when the client and server perform the same operation, 

on the client's column values at the time of the refresh Examples of the first scenario are when (a) the client updates 

request, the server effective operation, and the list of column and the server deletes the same row, (b) the client deletes and 

values representing the current key. the server updates the same row, and (c) the client and server 

A goal of refresh processing is to ensure that a client table insert the same row with different column values. Examples 

Tc contains the same data values as the corresponding server 65 of the second scenario are when (a) the client and server both 

table Ts at the completion of the refresh operation. Instead delete the same row, and (b) the client and server both insert 

of sending all rows and columns of the server table Ts to the the same row with the same column values. 
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In these scenarios, the server performs no operations on While the server is determining the SEO during the client 

behalf of the client in the synchronized table, so no record refresh process, it updates the value of any null refresh 

would normally appear in the SUL. Normal client refresh timestamp Rtu with the time at which the refresh process 

processing would, however, produce an incorrect result. A started, which becomes the new last-refreshed time of the 

Scnd-Insert or Send-Update signal is inserted into the SUL 5 client that is being refreshed. The server similarly updates 

so that client refresh processing can obtain a correct result. any refresn timestamp whose value is later than the new 

Because the Send-Insert and Send-Update signals do not last-refreshed time. This is done to make sure the server sees 

result from operations on the synchronized table, they are aU 0 ^ rations in the SUL ^ took place since lhe last 

effectively artificial entries in the SUL. refresh operation took place> even those whose traDsactiotl s 

Returning to FIG. 15B, a new client 20q may, at time t4, 1Q started rior tQ the start of the last refresh operation but 

attempt to insert a row using the key value k=4 which has which committed ^ or ^ the lasl refresQ operation . 

already been inserted at the server. Assuming that this new 0 , .. ,~ , . . . t r 

i* .» -i a i * c u • i- .i_ *t\ j n- * Such an operation would have an operation timestamp OPtu 

client s 20o last refresh is earlier than tO, dunng conflict ,• i . r ... . u . 

detection, the server destination calculates a Server Effective ™ hGT lhar \ the che u nt * last - r 5 fre u s h time > ■ V* wou } d n ° l have 

Operation (SEO) of Insert. If the resolution setting for insert been seen dunng the last refresh cycle because its transac- 

conflicts is for the server to prevail, then the server creates 15 Uon had not committed - 

an SUL entry for a Send-Update operation as shown. This As described, the server uses the SUL table Tu for two 
operation instructs the server source, during refresh purposes. The server uses the SUL table Tu to create a view 
processing, to send a complete update (i.e., all columns) to of the client's old values for conflict detection and then a 
the new client 20?, which synchronizes the new client 2Qq, view of the client's current values for refreshing the client. 
Note that no values are recorded for the non-key columns 20 goth views are deduced from the SUL table Tu without the 
Clu, C2u, C3u because they are not needed. client providing explicit information to the server. The 
For each changed row in the server table Ts, the server process is based on knowing what a client's values are at the 
uses the SEO, client before-values, and the filter predicate last refresh time and recreating client update activity from 
(from the catalog) to determine the client effective operation up d a te operations performed by that client since that time, 
and minimum set of data fields to send to the client 20*. 25 Consequently, the server can do conflict detection and can 
Shown below is pseudo-code for an algorithm used by the f ormu i ate the effective database operations needed to bring 
server to determine what message to send to the client. There the client int0 synchronization with the server while mini- 
are three inputs to the algorithm: the Server Effective mizing the amount of information communicated to the 
Operation (SEO), the result of a query to determine if the server by the client. 

row exists in the server table Ts when the filter predicate is 30 r. T -o **aj^™ u • j- r r 

applied (Tstfh)), and the result of a query on the SUL table FIGS ' \ 6A a ° d 1<B m f d TT S J \l t 

Tu in which the first operation following the last refresh is ° essa f f I f om mc TT-r ?™r\h ^ ^ ?* u 

, , * c .„ r ru 0 . /qi the updated server table Ts of FIG. 14A. The values for the 

examined to see if it satisfies the filter predicate flu(filt)). , f , , t c „ A n /A . , 

a v . l. „ ™- t i7 x T *■ A ♦ • updated data fields Rs(l)Cl and Rs(4)Cl must be propa- 

The resultmg operation is the Client Effective Operation \ , t t , t , \' , ^ 7 . c 

rr-nrw „ A ♦ .u i- * in r> *u • gated to the client node 20* because those values differ from 

(CEO) sent to the client 20*. Because the queries are 35 Tu 1 ■ j * c u iwi\oi a ™ ,a\ 

expensive to process, the algorithm is ordered so that Ts(fil.) ' h , e corresponding values m data fields Rc(l)Cl and Rc(4) 

and Tu(filt) are only calculated if necessary. CI of the chent table Tc. ^ these are both the firs index 

position into the server-side table correspondence Ls, the 
^ — fi^ 1 °i l °1 °f tne column identification field 57 is set and the 

if seo - - NOOp corresponding values A' and M' are placed in the value fields 

then CEO(filt) - None 40 59. The key value field 55 is set to the respective unique key 

Else if ((SEO - - Insert [| SEO - - Send-Insert) && Ts(filt) - - False) va l ues ( j e ^ « X » an(J « 4 ») Because all Other data field values 

Else if ((sbo -^isirt "\ seo - - Send-insert) && TsfFiit) - - True) are in between the server table Ts and the client 
then CEO(fiit) = insert table Tc, no other values are included in the refresh message. 
Else if (SEO^Send-Update && Ts(fiU) - False) ^ FIGS 17A and 17B are schematic diagrams of a synchro- 
Else if (SEol^Send Upd^&& Ts(rUt) - - True) nized client table Tc and the corresponding before-image log 
then CEO(flit) = Update (all data fields) table Th, respectively after applying the updates of FIGS. 
Else if (Ts(fiit) - - True && Tu(fUt) - - True) 15A and 15B. As illustrated, both data fields Rc(l)Cl and 
then CEO(fiit) - Update (changed fields only) Rc(4)Cl are updated to the values A' and M', respectively. 

Else if (Ts(filt) = - False && Tu fill) = - True) -ru u f • 1 * ui tv • a * j * 1 *u 

then CEO(fiit) - Delete so ^ before-image log table Tb is updated to equal the 

Else if (Ts(fiit) = - True && Tu(fUt) - - False) client-side database table Tc. The client node 2Qx t however, 

then CEO(filt) - insert is not required to accept the updates from the server 10. 

Else Error P or eac k ta ^j e re f res j, ( se t 0 f table modifications) 

accepted by the client node 20*, a refresh acknowledgment 

By applying the filter predicate, the server can determine 55 is returned to the server node 10. If any table refresh is not 
whether a row has been filtered into or filtered out of the set accepted by the client node 20*, no acknowledgment is 
of rows that should be possessed by client 20*. Filtering-in returned to the server node 10 for that table. For the above 
occurs when a data field value in the row changes such that example, an acknowledgment is returned for the table T 
the row satisfies the filter predicate. Filtering-out occurs Because the client node 20x accepted the server updates, the 
when a data field value changes such that the row no longer 60 refresh log entry is updated to reflect the time of synchro- 
satisfies the filter predicate. nization tl for the updated data fields. 

When sending an update message to the client, the server FIG. 18 is a schematic diagram of an updated refresh table 

uses the client's before-values (as calculated from the SUL) Tr of FIG. LLC. The last time of refresh t4 for the client node 

to determine which data field values to send to the client. 20* is recorded in the refresh time column Rt of the row 

The server sends only those values that differ from the 65 keyed by the client identifier "x" in the refresh table Tr. 

client's before-values, assuring that the minimum set of data When the refresh is completed at the time of synchronization 

field values is sent for each row that must be updated. (t3), t4 equals t3. 
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FIGS. 19A-19B are logic tables illustrating the use of a 
server effective operation during the database synchroniza- 
tion of FIGS. 8A-18. At time tO, the column values for the 
server table and the client table are both equal to "A" 
because the two tables are synchronized. The SUL table 5 
entry is as illustrated in FIG. 15B. At time tl, the column 
value in the server table is modified to "A" and the operation 
is recorded in the SUL table Tu as illustrated in FIG. 15B. 
At time t2.5, the column value at the client table changes to 
"A 11 ", but no synchronization occurs. Therefore, no entry JQ 
can appear in the SUL table Tu. 

At time t3 (FIG. 19 A), the client propagates its change 
value "A"" to the server. The server now walks through the 
server update log to determine a server effective operation. 
For time tO, the provisional before value is equal to "A". For 
time tl, an update to the column value from a source other 15 
than this client is logged in the SUL table Tu. As a result, the 
SEO is determined to be update with the provisional before 
value remaining of "A". Because the server has received 
instruction from the client to update the column value to 
"A"'*, the server detects an update conflict. As illustrated, the 20 
server retains its column value of "A"'. That is, at a later time 
t3.5, neither the server nor the client have changed their 
column values. 

At time t4 (FIG. 19B), the client request a refresh from the 
server. At time t4, the server again reads through the server 25 
update log table and determines a provisional before value 
of "A" for time tO and an SEO of update for time tl as above. 
An update operation, however, is read from the time t3 entry 
in the SUL table Tu of FIG. 15B. That update operation did 
not result from the client being refreshed. As a result, the 30 
SEO is calculated to be an update with a before value of "A". 
Because this row exists in both the server table Ts (FIG. 
15A) and the SUL table Tu (FIG. 15B), the client effective 
operation (CEO) is calculated to be an update for time t4. As 
a result of the update synchronization at time t4, the current 35 
value of the client table entry is equal to the current value 
from the server table ("A"). 

Although a one-to-one correspondence between the 
server table Ts and the client table Tc has been illustrated for 
ease of understanding the concepts of the invention, such a 4( > 
relationship between a client table Tc and a server table Ts 
is not required for the invention. Any server table can 
correspond to more than one table at a particular client. Such 
a relationship may be necessary where a client requires the 
same data to be available to multiple application programs, 4 5 
such as a database and a spreadsheet application. 

Although the invention has been described with reference 
to relational database tables, other database models can also 
be used at either the server or the client. For example, both 
object-oriented and relational databases structure data as a 50 
plurality of sub-collections of objects (or rows), each of 
which is of the same type (or has the same fields). A table 
of rows can thus be modeled as a collection of objects (often 
called a "class") with like attributes. Conversely, data in an 
object-oriented database may be represent able as tabular 55 
data having rows and columns of data fields. Consequently, 
the invention also applies to object-oriented databases to the 
extent that a given class has properties equivalent to that of 
a table in a relational database (e.g., data modifiable using 
insert, update and delete operations). Similarly, the inven- 60 
tion can be applied to other database models including, but 
not limited to, hierarchial and network (CODASYL) data- 
bases. 

Equivalents fi5 

Those skilled in the art will know, or be able to ascertain 
using no more than routine experimentation, many equiva- 
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lents to the specific embodiments of the invention described 
herein. For example, although various features have been 
described as software routines in a preferred embodiment of 
the invention, it is understood that those and other features 
of the invention can be embodied in software, hardware or 
firmware. These and all other equivalents are intended to be 
encompassed by the following claims. 
We claim: 

1. A method of synchronizing values of data items on a 
plurality of computers, comprising the steps of: 

storing a data item having a value at a first computer; 

at the first computer, maintaining a log of modification 
operations to the value of the data item, the value of the 
data item being modifiable by the first computer and in 
response to actions at a plurality of computers, includ- 
ing at a second computer; 

at the first computer, deriving a single effective operation 
from a plurality of modification operations maintained 
in the log, the effective operation yielding the same 
result on the value of the data item as would the 
plurality of modification operations; and 

using the effective operation to synchronize the value of 
the data item at the first computer with a value of a 
replica data item stored at the second computer. 

2. The method of claim 1 wherein the step of maintaining 
a log comprises the steps of: 

determining the class of a respective modification opera- 
tion; and 

based on the class, logging a value of the data item in the 
log, the logged value being either a before-value or an 
inserted value. 

3. The method of claim 1 wherein the step of deriving 
comprises iteratively processing the modification operations 
in the log. 

4. The method of claim 1 further comprising the step of 
detecting a conflict between modifications to the value of the 
data item and the value of the replica data item using the 
effective operation. 

5. The method of claim 4 wherein the step of detecting 
comprises: 

determining a deduced modification operation to propa- 
gate the value of the replica data item from the second 
computer to the first computer; and 

comparing the effective operation with the deduced modi- 
fication operation to yield a conflict state. 

6. The method of claim 5 wherein the modification 
operations include an operation from the group consisting of 
an insert, a delete and an update operation. 

7. A system for synchronizing values of data items on a 
plurality of computers, comprising: 

a value of a data item stored at a first computer; 

a log of modification operations to the value of the data 
item maintained at the first computer, the value of the 
data item being modifiable by the first computer and in 
response to actions at a plurality of computers, includ- 
ing at a second computer; 

an effective operation derived at the first computer from 
a plurality of modification operations in the log, the 
effective operation calculated to yield the same result to 
the value of the data item as would the plurality of 
modification operations; and 

a database synchronizer to synchronize the value of the 
data item with a value of a replica data item stored on 
the second computer using the effective operation. 

8. The system of claim 7 wherein the log comprises a class 
of a respective modification operation and a logged value of 
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the data item, the logged value being either a before value 
or an inserted value based on the class. 

9. The system of claim 7 wherein the effective operation 
comprises an iterative processing of the modification opera- 
tions in the log. 5 

10. The system of claim 7 wherein the database synchro- 
nizer comprises a conflict detector to detect a conflict 
between modifications to the value of the data item and the 
value of the replica data item using the effective operation. 

11. The system of claim 10 wherein the conflict detector 10 
comprises: 

a deduced modification operation calculated to propagate 
the value of the replica data item from the second 
computer to the first computer; and 

a conflict state yielded from comparing the effective 15 
operation with the deduced modification operation. 

12. The system of claim 11 wherein the modification 
operations are selected from the group of operations con- 
sisting of an insert, a delete and an update operation. 

13. A method of synchronizing values of data items on a 20 
plurality of computers, comprising the steps of: 

maintaining a first copy of a data item at a first computer; 

maintaining a replica copy of the data item at a second 
computer, the value of the replica copy differing from 25 
the value of the first copy; 

at the first computer, maintaining a log of modification 
operations to the value of the first copy, the value of the 
first copy being modifiable by the first computer and in 
response to actions at the second computer; 30 

at the first computer, deriving an effective operation from 
a plurality of modification operations maintained in the 
log, the effective operation yielding the same result on 
the value of the first copy as would the plurality of 
modification operations; 35 

from the effective operation, deducing at the first com- 
puter a before value of the replica copy stored at the 
second computer; 

at the first computer, detecting a conflict between modi- 
fication to the values of the first copy and the replica 40 
copy using the deduced before value; and 

applying the effective operation to resolve the conflict. 

14. The method of claim 13 wherein the plurality of 
computers form a client-server computing system, the first 
computer being a server and the second computer being a 45 
client. 

15. The method of claim 13 wherein the step of main- 
taining a first copy comprises the steps of: 

defining a database structure having plurality of organized 5Q 

data fields; and 
storing the current value of the first copy in a data field of 

the database. 

16. The method of claim 13 wherein the step of main- 
taining a log comprises the steps of: 55 

determining the class of a respective modification opera- 
tion; and 

based on the class, logging a value of the first copy in the 
log, the logged value being either a before value or an 
inserted value of the first copy. 60 

17. The method of claim 13 wherein the step of deter- 
mining an effective operation comprises an iterative pro- 
cessing of the modification operations in the log and a 
determination of the existence of a value for the first copy 
stored on the first computer. 65 

18. The method of claim 13 wherein the step of detecting 
a conflict comprises the steps of: 
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determining a deduced modification operation to propa- 
gate the value of the replica copy from the second 
computer to the first computer; and 

comparing the effective operation with the deduced modi- 
fication operation to yield a conflict state. 

19. The method of claim 18 wherein the step of applying 
the effective operation comprises selecting a solution to the 
conflict based on the conflict state. 

20. A system for synchronizing values of data items on a 
plurality of computers, comprising: 

a first copy of a data item at a first computer; 

a replica copy of the data item on a second computer, the 

value of the replica copy differing from the value of the 

first copy; 

a log of modification operations to the value of the first 
copy maintained on the first computer, the value of the 
first copy being modifiable by the first computer and in 
response to actions at the second computer; 

an effective operation derived at the first computer from 
a plurality of modification operations in the log, the 
effective operation calculated to yield the same result to 
the value of the first copy as would the plurality of 
modification operations; 

a deduced before value of the replica copy derived at the 
first computer from the effective operation; 

at the first computer, a conflict detector for detecting a 
conflict between modifications to the values of the first 
copy and the replica copy from the deduced before 
value; and 

a conflict resolver for applying the effective operation to 
resolve the conflict. 

21. The system of claim 20 wherein the plurality of 
computers form a client- server computing system, the first 
computer being a server and the second computer being a 
client. 

22. The system of claim 20 further comprising a database 
structure having a plurality of data fields, the current value 
of the first copy being stored in a data field of the database. 

23. The system of claim 20 wherein the log comprises a 
logged value of the first copy, the logged value being either 
a before value or an inserted value of the first copy based on 
a determined class of the respective modification operation. 

24. The system of claim 20 wherein the effective opera- 
tion comprises an iterative processing of the modification 
operations in the log and a determination of the existence of 
a value for the first copy on the first computer. 

25. The system of claim 20 wherein the conflict detector 
comprises: 

a deduced modification operation calculated to propagate 
the value of the replica copy from the second computer 
to the first computer; and 

a conflict state derived from a comparison of the effective 
operation with the deduced modification operation. 

26. The system of claim 25 wherein the conflict resolver 
applies the effective operation by selecting a solution to the 
conflict based on the conflict state. 

27. A method of synchronizing values of data items on a 
plurality of computers, comprising the steps of: 

maintaining a first copy of a data item at a first computer; 

maintaining a replica copy of the data item at a second 
computer, the value of the replica copy differing from 
the value of the first copy; 

at the first computer, maintaining a log of modification 
operations to the value of the first copy, the value of the 
first copy being modifiable by the first computer and in 
response to actions at the second computer; 
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at the first computer, deriving an effective operation from 
a plurality of modification operations maintained in the 
log, the effective operation yielding the same result on 
the value of the first copy as would the plurality of 
modification operations; 

at the first computer, detecting a conflict between the 
values of the first copy and the replica copy; 

from the effective operation, deducing the value of the 
replica copy stored on the second computer; and 

forming a propagation operation from the effective opera- 
tion to modify the value of the replica copy on the 
second computer to be in synchronization with the 
value of the first copy on the first computer. 

28. The method of claim 27 wherein the step of main- 
taining a first copy comprises: 

defining a database structure having plurality of organized 

data fields; and 
storing the current value of the first copy in a data field of 

the database. 

29. The method of claim 27 wherein the step of main- 
taining a log comprises the steps of: 

determining the class of a respective modification opera- 
tion; and 

based on the class, logging a value of the first copy in the 
log, the logged value being either a before value or an 
inserted value of the first copy. 

30. The method of claim 27 wherein the step of deter- 
mining an effective operation comprises iteratively process- 
ing the modification operations in the log and a determina- 
tion of the existence of a value for the first copy stored on 
the first computer. 

31. The method of claim 27 wherein the step of detecting 
a conflict comprises the steps of: 

determining a deduced modification operation to propa- 
gate the value of the replica copy from the second 
computer to the first computer; and 

comparing the effective operation with the deduced modi- 
fication operation to yield a conflict state. 

32. The method of claim 31 wherein the step of forming 
the propagation operation further comprises selecting a 
solution to the conflict based on the conflict state. 

33. A system for synchronizing values of data items on a 
plurality of computers, comprising: 

a first copy of a data item stored at a first computer; 
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a replica copy of the data item stored at a second 
computer, the value of the replica copy differing from 
the value of the first copy; 

a log of modification operations to the value of the first 
copy maintained at the first computer, the value of the 
first copy being modifiable by the first computer and in 
response to actions at the second computer; 

an effective operation derived at the first computer from 
a plurality of modification operations in the log, the 
effective operation calculated to yield the same result to 
the value of the first copy as would the plurality of 
modification operations; 

at the first computer, a conflict detector for detecting a 
conflict between the values of the first copy and the 
replica copy; 

a deduced value of the replica copy derived from the 
effective operation; and 

a conflict resolver for forming a propagation operation 
from the effective operation to modify the value of the 
replica copy on the second computer to be in synchro- 
nization with the value of the first copy on the first 
computer. 

34. The system of claim 33 further comprising a database 
structure having a plurality of data fields, the current value 
of the first copy being stored in a data field of the database. 

35. The system of claim 33 wherein the log comprises a 
logged value of the first copy, the logged value being either 
a before value or an inserted value of the data item based on 
a determined class of the respective modification operation. 

36. The system of claim 33 wherein the effective opera- 
tion comprises an iterative processing of the modification 
operations in the log and a determination of the existence of 
a value for the first copy on the first computer. 

37. The system of claim 33 wherein the conflict detector 
comprises: 

a deduced modification operation calculated to propagate 
the value of the replica copy from the second computer 
to the first computer; and 

a conflict state derived from a comparison of the effective 
operation with the deduced modification operation. 

38. The system of claim 37 wherein the conflict resolver 
forms the propagation operation by selecting a solution to 
the conflict based on the conflict state. 
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